Optical networks and the like are deploying control plane systems and methods that span multiple layers (e.g., wavelength division multiplex (WDM), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), Ethernet, and the like). Control plane systems and methods provide automatic allocation of network resources in an end-to-end manner. Exemplary control planes may include Automatically Switched Optical Network (ASON) as defined in G.8080/Y.1304, Architecture for the automatically switched optical network (ASON) (February 2005), the contents of which are herein incorporated by reference; Generalized Multi-Protocol Label Switching (GMPLS) Architecture as defined in Request for Comments (RFC): 3945 (October 2004) and the like, the contents of which are herein incorporated by reference; Optical Signaling and Routing Protocol (OSRP) from Ciena Corporation which is an optical signaling and routing protocol similar to PNNI (Private Network-to-Network Interface) and MPLS; or any other type control plane for controlling network elements at multiple layers, and establishing connections there between. Control plane systems and methods use bandwidth advertisements to notify peer nodes of available link capacity. The bandwidth advertisements exchange information over a dedicated and well known communication channel with peers on opposite ends of the communication link.
With respect to GMPLS, for example, Internet Engineering Task Force (IETF) Open Shortest Path First (OSPF) extensions for GMPLS define how bandwidth is advertised, i.e. “Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks,” (September 2011), available online at tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07, the contents of which are incorporated by reference herein. The OTN strategy taken by the IETF is straight forward in that the Interface Switching Capability Descriptor (ISCD) indicates the available bandwidth for each individual container size. For example, an aggregated link of 4×Optical channel Transport Unit 3 (OTU3) interface with no label switched paths (LSPs) or subnetwork connections (SNCs) provisioned would advertise: Optical channel Data Unit 0 (ODU0): 128 (4×32), ODU1: 64 (4×16), ODU2: 16 (4×4), and ODU3: 4 (4×1). An Optical channel Data Unit flex (ODUFlex) is advertised as a separate value. An ISCD is sent whenever the available bandwidth changes on a link. Conventional bandwidth advertisement systems and methods including ISCDs introduce a scaling problem for large network domains and large links. For example, in state of the art OTN networks, dense wave division multiplexing (DWDM) links are typically 40 Gbps OTU3, and migrating to 100 Gbps OTU4. Customer traffic on such links is expected to include a large number of ODU0, ODU1, and ODU2 LSPs carrying Gigabit Ethernet (GbE), 10 GbE, and legacy Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH). ISCD messaging can become expensive to process during network restoration or reconfiguration as the available bandwidth of the link changes.
A conventional solution can include only advertising supported ODUk rates, i.e. advertise maximum supported capacity rather than advertising actual capacity. In this case, no update would be transmitted until the interface becomes incapable supporting a given ODUk rate. Using the 4×OTU3 aggregated link example from above, the starting bandwidth would simply be: {ODU0, ODU1, ODU2, ODU3}. If for example, a single ODU0 is taken on each line, a new message is transmitted advertising: {ODU0, ODU1, ODU2}. Continued use of ODU0 resources does not result in a further ISCD update until only 3 ODU0s remain on a line, at which point the advertised bandwidth becomes: {ODU0, ODU1}. This conventional solution is very efficient with respect to messaging, but it fails to address the case of an aggregated LSP utilizing multiple ODUk tributaries (due to the fact the actual number of available tributaries is not known by the control plane). Control planes are looking to support co-routed LSPs where a single client service is composed of N×GbE or N×10 GbE aggregated links, and the aforementioned conventional bandwidth advertisement solution is not an acceptable solution with such aggregated links.